Simulation modeling is commonly used to model systems to perform "what-if" analyses, to optimize system performance and to identify problems within systems. Graphical simulation modeling allows a complex system to be modeled in an intuitive and visually comprehensible manner, and has found application in wide range of fields, from business to biological analysis.
The construction of a simulation model typically involves identifying various objects within the system, which are then represented by variables, equations or both embodied in an "object". A simulation model may be constructed using a graphical user interface (GUI) in which the various objects are represented by user-selected icons or other appropriate graphical representations, and in which the inter-relationships between the objects are represented by links.
A simplified representation of a typical prior art graphical user interface (GUI) for a graphical simulation model is shown FIG. 1. Specifically, the prior art GUI of FIG. 1 includes a diagram window 10, within which are displayed node representations for various objects of a modeled system. Each of the various objects of the modeled system is shown to be either an entity object 12, an input object 14 or a link object 16. Each of the objects typically includes at least one parameter 18 which has a parameter name, an assigned value 20 and parameter documentation 22 which describes the parameter 18.
Known simulation modeling tools include the Process Charter from Scitor Corporation of Menlo Park, Calif.; PowerSim from Modell Data AS in Bergen, Norway (http://www.powersim.com); Ithink and Stella from High Performance Systems Incorporated of Hanover, N,H. (http://hps-inc.com); and Extend +BPR from Imagine That! Incorporated of San Jose, Calif. (http://www.imaginethatinc.com). FIG. 2 illustrates a simulation model 30 as generated utilizing the Ithink product from High Performance Systems, Inc. The simulation model represents a work-in/work-out system within a business. The simulation model 30 is shown to include an object 32 that represents "work backlog", the object 32 being fed by arriving work orders 34 and depleted by filled work orders 36. The rate at which work orders are fed to the backlog object 32 is determined by an object 39, which functions as a "valve" with respect to a pipe by which work orders are fed to the object 32. Similarly, the rate at which work orders are dispensed from the object 32 is dependent upon an object 38 which functions as a "valve" for the pipe by which work orders are dispensed from the object 32. The object 38 is shown to receive as inputs the number of workers within the system, as represented by object 42, and the weekly productivity of each of these workers, as represented by the input parameter 40. The weekly productivity of the workers is further a function of hours per week per worker, represented by object 44. The production per hour worked, represented by object 46, is further shown to influence the weekly productivity per worker. Productivity per hour worked is in turn influenced by an average burnout factor, which is represented by an object 48. Various other factors are shown to influence the object 48. While the simulation model 30 shown in FIG. 2 provides a satisfactory representation of the work-in/work-out system, the model 30 suffers from a number of inefficiencies. Specifically, the mathematical structure underlying the model 30 is not readily apparent from a viewing of the icons, and can only be guessed at as a result of the labels which are attached to the various nodes shown in the simulation model 30. Further, the numerous icons that are used to represent objects, inputs, pipes and links (as well as the labels associated with each of these icons) result in a cumbersome and cluttered depiction of the modeled system.